XDR is ‘hot’ en ‘the next best cybersecurity approach’. Althans, als je de meeste cybersecuritybedrijven moet geloven, die aanwezig waren op de afgelopen RSA Conference in San Francisco. Er zijn tegenwoordig heel veel cybersecuritybedrijven die aangeven dat ze XDR capable zijn.
Maar is XDR echt ‘the next best thing’? De term XDR is enkele jaren geleden verzonnen en vormgegeven door Nir Zuk, de oprichter/CTO van Palo Alto Networks. Hij noemde deze term voor het eerst tijdens een presentatie waarin hij liet zien dat Detection en Response niet alleen plaatsvindt bij het endpoint, maar ook in het netwerk en in de cloud(s). Kortom, een holistische aanpak van cybersecurity over het geheel van de te beveiligen organisatie.
Overkoepelend platform
Om deze holistische aanpak van cybersecurity te kunnen uitvoeren, is een overkoepelend platform nodig met sensoren in zowel het netwerk, de endpoints en de cloud. Vervolgens moet de data uit al deze sensoren in hetzelfde platform op een automatische manier worden verzameld, geanalyseerd en verwerkt. Dit resulteert vervolgens in geavanceerde (lees: snelle) actionable response. Dat is hoe Nir Zuk de term ‘XDR’ bedoelde.
Dan kun je jezelf afvragen of de cybersecurityproducten en -diensten van vooral point product vendors (CASB, EDR or MDR), daadwerkelijk XDR kunnen aanbieden? Of kunnen zij slechts een bijdrage toevoegen aan een XDR-concept? Ik denk het laatste.
XDR capable
Mijns inziens is er slechts een handjevol cybersecurityvendors die daadwerkelijk XDR kunnen invullen en toepassen. De overige vendors kunnen weliswaar een bijdrage leveren aan dit concept, maar gebruiken XDR vooral als ‘buzzword’ om business te genereren. Mijn advies is dan ook om vooral door te vragen als een vendor zichzelf ‘XDR capable’ noemt. Op het moment dat deze vendor daadwerkelijk toegeeft dat het ‘slechts’ een bijdrage kan leveren en zichzelf ondergeschikt maakt aan het geheel, dan begrijpt deze vendor XDR en kan XDR daadwerkelijk relevant zijn.
(Dit artikel verscheen eerder in ITchannelPRO magazine nummer 3)
